System, method, and API for progressively installing software application

ABSTRACT

Described is a mechanism for enabling an application operating as a web application to transition to a client-side application without impacting a user&#39;s interaction with the application. The progressive installation transitions through three states: a start-up state, a demand state, and an install state. During the start-up state, a subset of components associated with the application is downloaded and stored in a local data store. The subset is sufficient to allow execution of the application in a manner similar to a web application. During the demand state, additional resources associated with the application are downloaded. Transitioning from the demand state to the installed state occurs without impacting a user&#39;s interaction with the application. The transition may occur autonomously based on the number of additional resources stored in the local data store or upon an external trigger.

RELATED APPLICATIONS

[0001] This application is a Continuation-in-Part of pending U.S. patentapplication Ser. No. 10/444,699, filed on May 22, 2003, entitled SYSTEMAND METHOD FOR PROGRESSIVELY INSTALLING A SOFTWARE APPLICATION in thenames of Mark Alcazar, Michael Dunn, Adriaan Carter, and Prasad Tammana,incorporated by reference herein.

BACKGROUND OF THE INVENTION

[0002] There are two main types of applications available today. A firsttype of application is a client-side application. The client-sideapplication resides on a client computer and is available for usewhenever the client computer is operational. This client-sideapplication undergoes a distinct installation state before it isavailable for use. Typically, the installation state displays some formof a progress user-interface, such as a thermometer, duringinstallation. During the installation state, the client-side applicationis not available for use. The client-side application must be fullyinstalled before a user can use the application.

[0003] The other type of application is commonly referred to as a Webapplication or Web app. The Web app is stored on a Web server. The Webapp is commonly deployed as multiple Web pages accessible over theInternet. A conventional Web app includes multiple Web pagesrepresenting markup-based documents. The Web app may also includescripts or other resources that are accessed through the Web pages. Formost Web apps, the multiple Web pages and resources are hyperlinkedtogether in such a way that the “business logic” of the Web app isdistributed over the multiple resources. Each page is responsible for aportion of the overall business logic, and, by navigating from page topage, the user can experience the entire Web app. For the purpose ofthis document, the term “navigating” refers to causing a hostingenvironment to retrieve a resource associated with the Web app, such asby activating a hyperlink. Navigating to a resource typically involvesnavigating away from another resource where the navigated-to resource isthe one being retrieved by the hosting environment. Web apps do notrequire an installation phase and are not available once the clientcomputer is disconnected from the Web server.

[0004] Both of these methods for interacting with a software applicationhave advantages and disadvantages, neither one is ideal.

SUMMARY OF THE INVENTION

[0005] The present invention provides a system and method forprogressively installing a software application so that a user may begininteracting with the application immediately. Then, while interactingwith the application, the application may be progressively installed onthe user's computer, and if desired, become available offline at a latertime. The progressive installation includes three states: a startupstate, a demand state, and a final state. None of the states require adedicated installation phase in which the application is unavailable foruse. Instead, the progressive installation of the present inventionblends the two forms of application installation in a manner such thatthe Web app may be interacted with as a conventional Web app, and thensmoothly transitioned to a client-side application without impacting theuser's interaction with the application.

[0006] The invention provides a mechanism for progressively installingan application. The progressive installation transitions through threestates: a start-up state, a demand state, and an install state. Duringthe start-up state, a subset of components associated with theapplication is downloaded and stored in a local data store. The subsetis sufficient to allow execution of the application in a manner similarto a web application. During the demand state, additional resourceassociated with the application are downloaded upon activation of ahyperlink on a Web page associated with the application. The additionalresources that are on demand resources are stored in the local datastore. The additional resources that are online resources are stored ina transient cache. During the installed state, the application executesin a manner similar to a client-side application. Transitioning from thedemand state to the installed state occurs without impacting a user'sinteraction with the application. The transition may occur autonomouslybased on the number of additional resources stored in the local datastore or upon an external trigger. During the transition, additionalresources that have not been previously downloaded are downloaded to thelocal data store. In addition, state derived during the demand state issaved with the application, which allows the application to resume fromthe same state when executed offline.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007]FIG. 1 illustrates an exemplary computing device that may be usedin one exemplary embodiment of the present invention.

[0008]FIG. 2 is a functional block diagram overview of a distributednetworking environment in which implementations of the invention may beembodied.

[0009]FIG. 3 is an illustrative screen display that may be presented byWeb browsing software for enabling the progressive download of anapplication, in accordance with one implementation of the invention.

[0010]FIG. 4 is a state diagram illustrating various states of theprogressive installation of an application, in accordance with oneimplementation of the invention.

[0011]FIG. 5 is a logical flow diagram generally illustrating a processduring a start-up state of the progressive installation.

[0012]FIG. 6 is a logical flow diagram generally illustrating a processduring a demand state of the progressive installation.

[0013]FIG. 7 is a logical flow diagram generally illustrating a processfor transitioning between the demand state and an install state of theprogressive installation.

[0014]FIGS. 8-10 are a series of block diagrams graphically illustratingfiles that are loaded during the progressive installation, in accordancewith one implementation of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0015] Briefly, the present invention provides a system and method forprogressively installing a software application so that a user may begininteracting with the application immediately. Then, while interactingwith the application, the application may be progressively installed onthe user's computer, and, if desired, installed in a manner such thatthe application is available offline at a later time. The progressiveinstallation includes three states: a startup state, a demand state, anda final state. None of the states require a dedicated installation phasein which the application is unavailable for use. Instead, theprogressive installation of the present invention blends the two formsof application installation in a manner such that the Web app may beinteracted with as a conventional Web app, and then provides a mechanismfor smoothly transitioning the application to an offline applicationwithout impacting the user's interaction with the application.

[0016] Exemplary Operating Environment

[0017]FIG. 1 illustrates an exemplary computing device that may be usedin one exemplary embodiment of the present invention. FIG. 1 illustratesan exemplary computing device that may be used in one exemplaryembodiment of the present invention. In a very basic configuration,computing device 100 typically includes at least one processing unit 102and system memory 104. Depending on the exact configuration and type ofcomputing device, system memory 104 may be volatile (such as RAM),non-volatile (such as ROM, flash memory, etc.) or some combination ofthe two. System memory 104 typically includes an operating system 105,one or more program modules 106, and may include program data 107. Thisbasic configuration is illustrated in FIG. 1 by those components withindashed line 108.

[0018] Computing device 100 may have additional features orfunctionality. For example, computing device 100 may also includeadditional data storage devices (removable and/or non-removable) suchas, for example, magnetic disks, optical disks, or tape. Such additionalstorage is illustrated in FIG. 1 by removable storage 109 andnon-removable storage 110. Computer storage media may include volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information, such as computerreadable instructions, data structures, program modules, or other data.System memory 104, removable storage 109 and non-removable storage 110are all examples of computer storage media. Computer storage mediaincludes, but is not limited to, RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed bycomputing device 100. Any such computer storage media may be part ofdevice 100. Computing device 100 may also have input device(s) 112 suchas keyboard, mouse, pen, voice input device, touch input device, etc.Output device(s) 114 such as a display, speakers, printer, etc. may alsobe included. These devices are well know in the art and need not bediscussed at length here.

[0019] Computing device 100 may also contain communication connections116 that allow the device to communicate with other computing devices118, such as over a network. Communication connections 116 is oneexample of communication media. Communication media may typically beembodied by computer readable instructions, data structures, programmodules, or other data in a modulated data signal, such as a carrierwave or other transport mechanism, and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. The term computer readable media asused herein includes both storage media and communication media.

[0020] Exemplary Networked Environment

[0021]FIG. 2 is a functional block diagram overview of a distributednetworking environment in which implementations of the invention may beembodied. As illustrated in FIG. 2, two or more computers, such as aserver 202 and a client computer 220, are connected over a network 205.Server 202 and client computer 220 are computing devices such as the onedescribed above in conjunction with FIG. 1. The computers may beconnected in a corporate environment, where the network 205 may be alocal area network or a wide area network. Similarly, the computers maybe arbitrarily connected over a wide area network, such as the Internet.

[0022] The server 202 is a computing device that is configured to makeresources available to other computing devices connected to the network205. The server 202 may include Web serving software to serve Internetrelated resources, such as HyperText Markup Language (HTML) documentsand the like. The server 202 includes local storage in the form of aserver data store 210. On the server data store 210 are at least some ofthe resources made available by the server 202 over the network 205. Inparticular, a deployment manifest 212 is stored on the server data store210, as well as an application package 214 and additional applicationresources 216, which are described in detail later in conjunction withFIGS. 8-10. The server 202 also includes other applications forconstructing and maintaining the deployment manifest 212, as well asother related documents and resources. In this implementation, theserver 202 makes the application package 214 and the additionalapplication resources 216 available over the network 205 to othercomputing devices.

[0023] The client computer 220 is a computing device configured toexecute locally-running applications as well as connect to othercomputers over the network 205. The client computer 220 also includeslocal storage in the form of a client data store 228. On the client datastore 228 resides an application store 230 and a transient cache 232. Inone embodiment, each application executing on client computer 220 has anassociated application store 230. The client computer 220 also includesother applications for interacting with other computers over thenetwork. One such application is host software 222, such as Internetbrowsing software (hereinafter referred to as browser 222). The browser222 communicates with an application package handler 224 and a resourceloader 226. The application package handler 224 is registered so thatwhen the browser 222 encounters an application package, such asapplication package 214, the browser knows to call the applicationpackage handler 224. The application package handler 224 then processesthe application package 214. The application package 214 containsinformation to start execution of the associated application on theclient computer 220. The format for the application package 214 may bean executable file or other packaging type format. In one embodiment,the application package handler 224 may be configured to decipher theformat of the application package in order to obtain the relevantinformation. The browser 222 also communicates with the resource loader226 when the client computer requests additional resources from theserver 202, such as additional application resources 216. The processingperformed by browser 222, application package handler 224, and resourceloader 226 will be described in greater detail below in conjunction withflow diagrams FIGS. 5-7.

[0024] Briefly stated, a user of the client computer 220 may connect tothe server 202 in any conventional manner. The server 202 presents a Webpage or some other resource that makes available files that reside onthe server data store 210. In response to a selection of a link or thelike by the user, the server 202 navigates to the deployment manifest212, which identifies the application package 214 associated with therequested application. As will be described in greater detail below, theapplication package 214 contains the minimum amount of code necessary tostart the application. The application package 214 is brought down tothe client computer 220 from the server 202.

[0025]FIG. 3 is an illustrative screen display that may be presented byWeb browsing software enabling the progressive download of a remoteapplication, in accordance with one implementation of the invention.Turning briefly to FIG. 3, an example display 300 of the browser 222 isshown including a Web page 310 that may be served by the server 202described above. The Web page 310 may be a resource associated with aparticular Web app or may be a resource for making available softwareapplications to remote computing systems for download. The Web page 310includes a hyperlink 360 pointing to the deployment manifest 212described above. The deployment manifest 212 points to the applicationpackage 214, which contains at least the minimum code necessary to startthe application. The Web page 310 also includes a hyperlink 380 pointingto the deployment manifest 212 described above. The selection ofhyperlink 380 indicates that the user is now interested in explicitly“installing” the application. As will be described in detail below inconjunction with FIG. 7, upon selecting hyperlink 380, the user maycontinue to interact with the application without waiting for theapplication to download or become installed on the computer.

[0026] It will be appreciated that the Web page 310 may be provided overthe Internet, a corporate intranet, or any other network-accessiblelocation. Activating the hyperlink 360 causes the application package214 to be pulled down from the server. It should be appreciated that theWeb page 310 is only one way that the user may invoke the application.For instance, a link to the application package 214 may be provided inan e-mail message, or the like.

[0027] Illustrative Techniques

[0028]FIG. 4 is a state diagram 400 illustrating various states of theprogressive installation of an application, in accordance with oneimplementation of the invention. The progressive installation includesan invoke state 402, a start-up state 404, a demand state 406, and aninstalled state 410. At the invoke state 402, a user as invoked theapplication. If the user invokes the application by clicking a link thatis served by server 202, the progressive installation proceeds to thestart-up state 404. However, as will be described later in detail, theapplication may have become installed on the client computer already.The locally installed application may be invoked, such as by selecting alink to the local application, selecting a short-cut in the start menuto the local application, and the like. When the locally installedapplication is invoked, the process transitions to the installed state410. In another embodiment, the transition to the installed state 410from the invoke state 402 may proceed via a subscription update state412. Briefly, the subscription update state 412 determines whether thereis an update to the application available on the server 202. If thereare any updates, the updated components of the application aredownloaded.

[0029] Now, assuming that the application has not been installedlocally, the progressive installation proceeds to the start-up state404. Briefly, described in detail in conjunction with FIG. 5, thestart-up state 404 downloads the minimum code necessary for theapplication to run on the client computer. Because, the minimum code isconsiderably less than the full application, the user can begininteracting with the application right away, similar to a user'sexperience when interacting with a traditional Web app today. From thestart-up state, the progressive installation proceeds to the demandstate 406. Briefly, described in detail in conjunction with FIG. 6, thedemand state 406 downloads resources as needed. This allows the user totry the application before committing to purchasing the application ordeveloping a lasting relationship with the application.

[0030] From the demand state 406, the user may proceed to the exit state408, foregoing the installation of the application locally. This mayoccur when the user closes the browser. Once the user transitions fromthe demand state 406 to the exit state 408, the downloaded components ofthe application may be deleted. Therefore, the client computer is in thesame state as before the user invoked the application. The user may thenlater invoke the remote application again. The progressive installationwill proceed again through the startup state and demand state. Thus, theuser may use the application again without committing to installing theapplication. From the demand state 406, the progressive installation maytransition to the installed state 410. The transition may beuser-initiated based on a purchasing decision, a request for elevatedpermission (e.g., trust elevation), or may be performed autonomous bythe operating system, such as when a pre-determined number of resourceshave already been installed on the client computer. The transition fromthe demand state to the installed state does not impact the user'sinteraction with the application. This transition is described below inconjunction with FIG. 7.

[0031] Thus, the progressive installation in accordance with the presentinvention allows a user to begin interacting with an application as soonas it is invoked. Pieces of the application are downloaded as the userinteracts without impacting the user. At no time, does the user need towait for a dedicated installation.

[0032]FIG. 5 is a logical flow diagram generally illustrating a processduring a start-up state of the progressive installation in accordancewith one embodiment of the present invention. The process begins atblock 501 where an application residing over a network as been invoked,such as by selecting a hyperlink related to the application. Beforecontinuing with FIG. 5, the components of the application residing overthe network are described in conjunction with FIG. 8.

[0033]FIG. 8 is a graphical depiction of the components of theapplication residing over the network on server 202. The componentsinclude the deployment manifest 212, the application package 214, andadditional application resources 216. The application package 214includes an application manifest 802 and code 804. The applicationmanifest 802 describes the application code in detail including eachcomponent, their versions and dependencies. A sample applicationmanifest of such a nature is included with this document as “AppendixA—Sample Application Manifest.” Although described in this document as aspecific file, the application manifest 212 of the invention should beinterpreted to mean information describing the components of theapplication in any form and it may exist in locations other than justthose described here. The application manifest 212 described here is byway of illustration only. In one embodiment, the code 804 includes theminimal code necessary to run the application. As one skilled in the artwill appreciate, additional, non-necessary code may be included withinapplication package 214 without departing from the present invention.However, in order to have the less delay or impact to the user, theminimal amount of code is desired. The additional application resources216 include on demand resources and online resources, such as markup A810, additional code 812, markup B 814 and the like. While FIG. 8,illustrates only five additional resources, one skilled in the art willappreciate that, typically, there are several additional resources thatare components of the Web app.

[0034] Returning to FIG. 5, at block 502, navigation to the deploymentmanifest 212 occurs in one embodiment of the present invention. In oneembodiment, the deployment manifest resides on a remote server andidentifies an entry point for the application. A sample deploymentmanifest is included with this document as “Appendix B—Sample DeploymentManifest.”

[0035] At block 504, navigation to the entry point occurs. In oneembodiment, the entry point may be an application package (e.g.,application package 214 shown in FIG. 8) that includes an applicationmanifest and the minimum amount of code necessary to run theapplication.

[0036] At block 506, the host is initiated. In one embodiment, the hostis a web browser. In another embodiment, in which the application isbeing progressively installed from the client computer, the host may bea standalone host. The standalone host will then function in the samemanner as described below using the embodiment in which the host is aweb browser. The application package handler is registered for the filetype associated with the application package. Therefore, when thebrowser receives the application package, the application packagehandler may initiate the progressive installation in accordance with thepresent invention. In one embodiment, the application package handlermay be a mime handler that is registered for the file type associatedwith the application package 214.

[0037] At block 508, the minimum amount of code necessary to run theapplication is downloaded. For the embodiment using the applicationpackage 214, this includes downloading the application package 214. Asmentioned above, the browser will call the application package handlerto process the application package 214.

[0038] At block 510, the resource loader is registered and associatedwith the application. The resource loader is responsible for loadingapplication resources as they are needed. In one embodiment, theresource loader may be a pluggable protocol that knows how to loadresources “in the context” of an application.

[0039] At block 512, an application domain for the application iscreated. At block 514, the user code that constitutes the application isexecuted. In one embodiment, the execution of the application creates anapplication object. Code within the application package that defines aclass is executed to create the application object. The applicationobject has a unique identity. In addition, the application objectincludes a state. The state will be continuously updated during thedemand state. The state includes information related to the user'sinteraction with the application. This state information will allow theapplication to smoothly transition from a web application to a clientapplication.

[0040] Processing in the start-up state is complete. The progressiveinstallation will then proceed to the demand state. As shown in FIG. 8,after the start-up is complete, the application package 214 is stored inthe application store 230 on the client computer 220. The user may begininteracting with the application. For prior Web apps, resources of theweb app were downloaded to the transient cache 232 without having theconcept of a per application store 230. As will be shown, by having theper application store 230, the present invention may smoothly transitionfrom a web app to a client-side application without impacting the user.

[0041]FIG. 6 is a logical flow diagram generally illustrating a processduring a demand state of the progressive installation. The demand statebegins at block 601 where the startup state is completed and the user isinteracting with the application. Process 600 depicts processing thatoccurs whenever a part of the application is requested. This mayincludes requests for assembly loads (code), resources, and the like.Typically, many requests for resources and code will be received duringthe demand state. Each such request will perform process 600. Thefollowing discussion describes process 600 when the request is aresource. Those skilled in the art will appreciate that process 600 isalso performed when the request is for an assembly load.

[0042] At block 602, a request is received. Typically, the requestoccurs whenever a user selects a hyperlink on one of the web pagesassociated with the application. Processing continues to decision block604.

[0043] At decision block 604, a determination is made whether therequest is for a resource. If the request is not for a resource,processing proceeds to the end. On the other hand, when the request isfor a resource, processing continues to decision block 606.

[0044] At decision block 606, a determination is made whether therequested resource is available locally. If the resource is availablelocally, the local copy of the resource is loaded for use and theprocess proceeds to the end. Depending on the type of resource, thelocal copy may either be in the application store or in the transientcache. If the resource is not available locally, processing continues atdecision block 610.

[0045] At decision block 610 a determination is made whether therequested resource is an on demand resource. If the requested resourceis an on demand resource, processing continues to block 612 where theresource is loaded via http and cached in the local application store.For example, in FIG. 9, markup A 810 and code 812 are stored in theapplication store 230. The process proceeds to the end. At decisionblock 610, if the resource is not an on demand resource, processingcontinues to decision block 620.

[0046] At decision block 620, a determination is made whether theresource is an online resource. If the resource is an online resource,processing continues to block 622 where the online resource is loadedvia http. At block 624, the online resource is cached in the transportcache 232. For example, in FIG. 9, markup b 814, which is designated asan online resource, is stored in the transient cache. Processing is thencomplete.

[0047] In one embodiment, each resource may belong to a group ofresources that are related in some fashion. For instance, resources thatare commonly used together may be included in a group. In such a case,at blocks 612 and 622 the entire group of resources including thesubject resource may be retrieved. This technique improves thelikelihood that another resource that will be needed later will alreadyexist locally.

[0048] Thus, as one will note, during the demand state, additionalresources are downloaded and are populated in the per application store.Because these resources that are download are the same resources thatare needed to run the application offline, as will be described below,the application store, along with the application object, allow thepresent invention to smoothly transition from a web application to aclient-side application without impacting the user's interaction withthe application. Thus, instead of having two different types ofapplication, (i.e., a client-side application and a web application),one type of application may be used for both purposes. Using the presentinvention, the one type of application smoothly transitions from onepurpose to the other purpose when desired.

[0049]FIG. 7 is a logical flow diagram generally illustrating a processfor transitioning between the demand state and the install state of theprogressive installation. Processing begins at block 701 where a triggerhas occurred to signal that the application should be installed. Thetrigger may be user-initiated or may be autonomous based on an externalbenchmark, such as the number of resources that have already beendownloaded into the per application store. Processing continues at block702.

[0050] At block 702, the remaining on demand resources are downloadedvia http. Processing continues at block 704. At block 704, theseremaining on demand resources are stored in the application store. Thisoccurs while the user is still interacting with the application. Forexample, FIG. 10 illustrates Markup C 816 now residing in theapplication store. Processing continues at block 706.

[0051] At block 706, a copy of online resources is stored in theapplication store 230. Therefore, if the copy in the transient cache isremoved, a copy of the online resource still exists. For example,referring to FIG. 10, Markup B 814 is illustrated as being stored in theapplication store. Processing continues at block 708.

[0052] At block 708, activation information is recorded in the operatingsystem. For example, a shortcut may be added to the start menu. Theactivation information allows the application to be invoked usingtraditional mechanisms the next time the application is invoked locally.Processing continues at block 710.

[0053] At block 710, impression information is recorded in the operatingsystem. The impression information describes the manner in which theapplication interacts with the operating system, such as fileassociations. In addition, the impression information describes how theapplication may be changed/removed from the program entries. Referringto FIG. 10, activation information 832 and impression information 834are shown within operating system information 830 on the client computer220. Processing is then complete.

[0054] At mentioned above, at this point, the application is availableoffline. As one notes after reading the above description, the user didnot have to wait for the installation of the application. Informationgenerated during the demand state is transitioned to the installedstate. Thus, through the use of the application identity and stateinformation that was stored while the user was interacting with theapplication, the application may smoothly transition to the installstate.

[0055] Illustrative Application Programming Interface

[0056] In one specific example, the above-described techniques may beimplemented with one or more Application Programming Interfaces (APIs)that expose functionality for managing the details of download andinstall, servicing, establishment of trust an privacy, and ultimateexecution of the application. One example of such an API is described inthe following example class for a DeploymentManager for handling each ofthese functions. What follows is a skeleton type-definition for thisDeploymentManager: public class DeploymentManager {   publicDeploymentManager(string identity, string codebase)   { ... }   // Theevents for the async operations which can be invoked.   public eventBindCompletedEventHandler BindCompleted;   public event  DeterminePlatformRequirementsCompletedEventHandlerDeterminePlatformRequirementsCompleted;   public eventDetermineAuthorizationCompletedEventHandlerDetermineAuthorizationCompleted;   public eventSynchronizeCompletedEventHandler SynchronizeCompleted;   public eventExecuteCompletedEventHandler ExecuteCompleted;   // ProgressChangedevent for all async operations.   public eventDeploymentProgressChangedEventHandler DeploymentProgressChanged;   //BindAsync   public void BindAsync(object userToken)   { ... }   //DetermineRequirementsAsync   public voidDeterminePlatformRequirementsAsync(object userToken)   { ... }   //DetermineAuthorizationAsync   public void DetermineTrustAsync(objectuserToken)   { ... }   // SynchronizeAsync   public voidSynchronizeAsync(object userToken)   { ... }   // ExecuteAsync   publicvoid ExecuteAsync(object userToken)   { ... }   // AsyncCancel   publicvoid AsyncCancel( )   { ... } }

[0057] Note that the DeploymentManager exposes methods for fiveprincipal operations: (1) Manifest Binding, (2) Determination ofPlatform Requirements, (3) Determination of Authorization, (4)Synchronization, and (5) Execution. Each of those functions shall bebriefly described here.

[0058] Manifest Binding

[0059] Manifest Binding is the process by which necessary manifestmetadata about a deployed application is initially obtained for thepurposes of install, servicing and activation. Binding generally beginswith either a codebase to a deployment manifest, or a deployedapplication identity, or possibly both. Binding retrieves the minimumset of manifest information for making subsequent decisions about thedeployed application. Manifest binds may or may not require networkconnectivity depending on the context of the bind, the state ofapplication store and the application being bound to. If an applicationis already deployed on the machine, a bind may succeed in a completelyoffline manner, with no network I/O.

[0060] Determination of Platform Requirements

[0061] Once binding is complete it becomes possible to query the installstate of the client machine to determine whether the necessary platformsare present to run the application. Platforms may be identified as anysoftware upon which the application depends but cannot be installed aspart of the deployed application install. Deployed applicationsreference these dependencies in their application manifest. Forinstance, support may be provided for minimum version of operatingsystem, minimum version of runtime environment, and specific version ofa GAC-resident assembly. Whether the version is treated as minimum maydepend on whether the assembly is marked as a platform or a library.

[0062] If platform requirements are satisfied, the application installcontinues. If platform requirements are not satisfied then a failure isreturned along with specific information on which platform dependencieswere not satisfied. The application install process then cannot proceedbut may be repeated after action is taken to install the necessaryplatforms on the machine.

[0063] Determination of Authorization

[0064] Decisions about what trust, privacy and licensing is to beaccorded to the application can also be made once Manifest Binding iscomplete, since this information may also be resident in the deploymentand application manifests. These decisions are grouped under the generalcategory of Authorization. Authorization may require user prompting,e.g., if the application cannot run in the default sandbox. SuccessfulAuthorization results in the generation of the set of permission grants,privacy policy guarantees, license keys, etc necessary for theapplication to run on the client machine. This information may be cachedso that the decision does not have to be repeated later when theapplication is activated. If Authorization fails then applicationinstall cannot proceed.

[0065] Synchronization

[0066] Upon successful completion of Platform and Authorizationdetermination, the actual task of installing the application payload canbegin. This process is known as synchronization. A synchronizationoperation may succeed by simply ensuring that the required version ofthe deployed application is already present on the machine.Alternatively, synchronization may involve a full download of theremotely deployed application (required as well as on-demand components,language packs) or only the minimum required subset of componentsnecessary to launch the application (e.g., required components only).When downloads are incurred synchronization can be further subdividedinto two phases: (1) a pure transport phase where the applicationpayload is replicated into a temporary storage location on disk and (2)a commit operation, where the deployed application is transacted tostore and made available for binding. Synchronization can also be usedto download the optional or on-demand components of a existing installedapplication.

[0067] Execution

[0068] Once an application has successfully completed Platform andAuthorization decisions, and its payload has been successfullysynchronized and committed to store, the application may then beexecuted (launched or run). Execution may take place in a separate,stand-alone process or may use the existing caller's process to run. Inboth cases the execution host provides a secure execution environmentfor the application, possibly utilizing previously cached decisionspreviously resulting from calls to Authorization to avoid reprompting.

[0069] Client-Side Implementations

[0070] To receive notifications from DeploymentManager methodinvocations, such as asynchronous completion results, the clientprovides an implementation for the associated completion event handlers(e.g., BindCompletedEventHandler, etc). These are passed an associatedcompletion event argument (e.g., BindCompletedEventArgs). To receiveasynchronous progress results for these operations, the client providesan implementation for DeploymentProgressChangedEventHandler. This willbe passed an argument (DeploymentProgressChangedEventArgs). What followsis a skeleton example of such an event-handler implementation: // Bindevent handler delegate and args. public delegate voidBindCompletedEventHandler(object sender, BindCompletedEventArgs e);public class BindCompletedEventArgs : AsyncCompletedEventArgs {   publicBindCompletedEventArgs(Exception error, bool cancelled, objectuserToken) : base(error, cancelled, userToken)   { ... } } //DeterminePlatformRequirements event handler delegate and args. publicdelegate void DeterminePlatformRequirementsCompletedEventHandler(objectsender, DeterminePlatformRequirementsCompletedEventArgs e); public classDeterminePlatformRequirementsCompletedEventArgs :AsyncCompletedEventArgs {   public  DeterminePlatformRequirementsCompletedEventArgs(Exception error, boolcancelled, object userToken) : base(error, cancelled, userToken)   { ...} } // DetermineAuthorization event handler delegate and args. publicdelegate void DetermineAuthorizationCompletedEventHandler(object sender,DetermineAuthorizationCompletedEventArgs e); public classDetermineAuthorizationCompletedEventArgs : AsyncCompletedEventArgs {  public DetermineAuthorizationCompletedEventArgs(Exception error, boolcancelled, object userToken) : base(error, cancelled, userToken)   { ...} } // Synchronize event handler delegate and args.  public delegatevoid SynchronizeCompletedEventHandler(object sender,SynchronizeCompletedEventArgs e); public classSynchronizeCompletedEventArgs : AsyncCompletedEventArgs {   publicSynchronizeCompletedEventArgs(Exception error, bool cancelled, objectuserToken) : base(error, cancelled, userToken)   { ... } } // Executeevent handler delegate and args. public delegate voidExecuteCompletedEventHandler(object sender, ExecuteCompletedEventArgse); public class ExecuteCompletedEventArgs : AsyncCompletedEventArgs {  public ExecuteCompletedEventArgs(Exception error, bool cancelled,object userToken) : base(error, cancelled, userToken)   { ... } } //DeploymentProgressChanged event handler delegate and args. publicdelegate void DeploymentProgressChangedEventHandler(object sender,DeploymentProgressChangedEventArgs e); public classDeploymentProgressChangedEventArgs : ProgressChangedEventArgs {   publicDeploymentProgressChangedEventArgs(object userToken, intprogressPercentage) : base(userToken, progressPercentage)   { ... } }

[0071] What follows is a general example of one implementation of aclient (e.g., an application) that invokes the mechanisms justdescribed. The following example is an application based on a class(Client) that implements the DeploymentManager described above. publicclass Client {   public static void Main( )   {     DeploymentManagerdep = new DeploymentManager(“name= bar, version=1.0.0.0”,“http://www.foo.com/bar.deploy”);     dep.DeploymentProgressChanged +=new DeploymentProgressChangedEventHandler(Client.ProgressChanged);    dep.BindCompleted += newBindCompletedEventHandler(Client.BindCompleted);    dep.BindAsync(null); }   public static void BindCompleted(objectsender, BindCompletedEventArgs e)   {    System.Console.WriteLine(e.ToString( ));   }   public static voidProgressChanged(object sender, DeploymentProgressChangedEventArgs e)   {    System.Console.WriteLine(e.ProgressPercentage);   } }

[0072] The above specification, examples and data provide a completedescription of the structure and use of implementations of theinvention. Since many embodiments of the invention can be made withoutdeparting from the spirit and scope of the invention, the inventionresides in the claims hereinafter appended.

Appendix A. Sample Application Manifest

[0073] <?xml version=“1.0” encoding=“utf-8”?> <assemblyxmlns=“urn:schemas-microsoft-com:asm.v1” manifestVersion=“1.0”xmlns:asmv2= “urn:schemas-microsoft-com:asm.v2”xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”xsi:schemaLocation=“urn:schemas-microsoft-com:asm.v1assembly.adaptive.xsd”>  <assemblyIdentity name=“MyDocViewer”version=“1.0.0.0” processorArchitecture=“x86” asmv2:culture=“en-us”publicKeyToken=“0000000000000000” />  <entryPoint name=“main”xmlns=“urn:schemas-microsoft-com:asm.v2” dependencyName=“MyDocViewer”>  <commandLine file=“MyDocViewer.exe” parameters=“” />  </entryPoint> <TrustInfo xmlns=“urn:schemas-microsoft-com:asm.v2”xmlns:temp=“temporary”>   <Security>    <ApplicationRequestMinimum>    <PermissionSet class=“System.Security.PermissionSet” ID=“FullTrust”version=“1” Unrestricted=“true” />     <AssemblyRequestname=“MyDocViewer” PermissionSetReference=“FullTrust” />   </ApplicationRequestMinimum>   </Security>  </TrustInfo>  <filename=“Sample4.xaml” hash=“75966580bf63a6f7d9818bcbf6c8c61343e61d9f”hashalg=“SHA1” asmv2:size=“636” />  <file name=“Sample5.xaml”hash=“9fe4e7312498c0b62ab455b289e27fc2fc8b3bb3” hashalg=“SHA1”asmv2:size=“615” />  <file name=“Sample6.xaml”hash=“760221281e78c621f45947b97b87e65a2bee6e14” hashalg=“SHA1”asmv2:size=“2750” />  <dependency asmv2:name=“MyDocViewer”>  <dependentAssembly>    <assemblyIdentity name=“MyDocViewer”version=“0.0.0.0” publicKeyToken=“f745653e2b97409d”processorArchitecture=“x86” />   </dependentAssembly>  <asmv2:installFrom codebase=“MyDocViewer.exe”hash=“95f2246ac74b3f32938db0ebed313e38ee7b4b5b” hashalg=“SHA1”size=“12288” />  </dependency> </assembly>

Appendix B. Sample Deployment Manifest

[0074] <?xml version=“1.0” encoding=“UTF-8” standalone=“yes”?> <assemblyxmlns=“urn:schemas-microsoft-com:asm.v1” manifestVersion=“1.0”xmlns:asmv2= “urn:schemas-microsoft-com:asm.v2”xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”xsi:schemaLocation=“urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd”> <assemblyIdentity name=“MyDocViewer.deploy”version=“1.0.0.0” processorArchitecture=“x86” asmv2:culture=“en-us”publicKeyToken=“0000000000000000” />  <descriptionasmv2:publisher=“MyCompany” asmv2:product=“WCP Application ofMyDocViewer” asmv2:supportUrl=“http://www.mycompany.com/AppServer/MyDocViewer/suppo rt.asp” /> <deployment xmlns=“urn:schemas-microsoft-com:asm.v2”isRequiredUpdate=“false”>   <install shellVisible=“true” />  <subscription>    <update>     <beforeApplicationStartup />    <periodic>      <minElapsedTimeAllowed time=“6” unit=“hours” />     <maxElapsedTimeAllowed time=“1” unit=“weeks” />     </periodic>   </update>   </subscription>  </deployment>  <dependency>  <dependentAssembly>    <assemblyIdentity name=“MyDocViewer”version=“1.0.0.0” processorArchitecture=“x86” asmv2:culture=“en-us”publicKeyToken=“0000000000000000” />   </dependentAssembly>  <asmv2:installFrom codebase=“MyDocViewer.manifest” />  </dependency></assembly>

We claim:
 1. A software architecture for installing an application on alocal computing system, comprising: a component configured to obtainmanifest metadata about the application for the purpose of installingthe application on the local computing system; and an applicationprogramming interface to access the component.
 2. The softwarearchitecture recited in claim 1, wherein the component is furtherconfigured to retrieve from the manifest a set of information sufficientto describe the application.
 3. The software architecture recited inclaim 1, wherein the application programming interface receives aparameter that identifies the application.
 4. A software architecturefor installing an application on a local computing system, comprising: acomponent configured to query the local computing system to determinewhether a platform necessary to the application is present on the localcomputing system; and an application programming interface to access thecomponent.
 5. The software architecture recited in claim 4, wherein theplatform comprises one or more software modules upon which theapplication depends that are not a part of the application.
 6. Thesoftware architecture recited in claim 5, wherein the platform furthercomprises one or more software modules that cannot be installed as partof the installation of the application.
 7. The software architecturerecited in claim 4, wherein the platform is identified in an applicationmanifest associated with the application.
 8. The software architecturerecited in claim 4, wherein the component is further configured toverify a version associated with the platform.
 9. The softwarearchitecture recited in claim 4, wherein the component is furtherconfigured to abort the installation of the application if the platformis not present.
 10. The software architecture recited in claim 9,wherein the component is further configured to return error informationin conjunction with aborting the installation of the application. 11.The software architecture recited in claim 10, wherein the errorinformation comprises identification information about which platformwas not present on the local computing system.
 12. A softwarearchitecture for installing an application on a local computing system,comprising: a component configured to determine whether the applicationis authorized for installation on the local computing system; and anapplication programming interface to access the component.
 13. Thesoftware architecture recited in claim 12, wherein the determination ofthe authorization comprises determining whether the installation of theapplication exceeds a trust level associated with a source of theapplication.
 14. The software architecture recited in claim 12, whereinthe determination of the authorization comprises determining whether theinstallation of the application violates a privacy policy associatedwith the local computing system.
 15. The software architecture recitedin claim 12, wherein the determination of the authorization comprisesdetermining whether the installation of the application violates alicense associated with the application.
 16. The software architecturerecited in claim 12, wherein the component is further configured togenerate a set of authorization parameters for the application if theapplication is authorized for installation.
 17. The softwarearchitecture recited in claim 16, wherein the set of authorizationparameters comprises at least permission grants, privacy policyguarantees, and license keys.
 18. A software architecture for installingan application on a local computing system, comprising: a componentconfigured to determine if a version of the application already existson the local computing system, and if not, to download at least oneresource associated with the application from a remote location; and anapplication programming interface to access the component.
 19. Thesoftware architecture recited in claim 18, wherein the resource issufficient to launch the application.
 20. The software architecturerecited in claim 18, wherein the component is further configured toreplicate the application to a temporary storage location at the localcomputing system.
 21. The software architecture recited in claim 18,wherein the component is further configured to commit the downloaded atleast one resource to storage on the local computing system and is madeavailable for binding.
 22. A software architecture for installing anapplication on a local computing system, comprising: a componentconfigured to execute the application on the local computing systemafter a successful determination that any necessary platform for theapplication is present on the local computing system and sufficientresources to launch the application are present on the local computingsystem, the resources being associated with the application; and anapplication programming interface to access the component.
 23. Thesoftware architecture recited in claim 22, wherein the component isfurther configured to abort execution of the application if theapplication is not authorized for execution on the local computingsystem.
 24. The software architecture recited in claim 22, whereinexecution occurs in a secure execution environment.
 25. The softwarearchitecture recited in claim 22, wherein execution occurs in a separateprocess from a calling entity responsible for the installation of theapplication.
 26. The software architecture recited in claim 22, whereinexecution occurs in the same process as a calling entity responsible forthe installation of the application.